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Aba  tract:  Tartan  i*  an  experiment  in  language  oesign.  Tha  feat  waa  to  datarmina  whathar 
a "simple*  lanfuafa  raid  meat  subetantiaffy  all  of  tha  Ironman  requirement  for  a common 
high-order  proframmmf  lanfuafa. 

Wa  undertook  thie  experiment  because  we  believed  that  ail  tha  deeifne  dona  in  tha  first 
pnaaa  at  tha  OCO  effort  ware  too  larfe  and  too  complex.  Wo  saw  that  complexity  aa  a 
serioua  failure  of  tha  deeifne:  excase  complexity  in  a proframmmf  lanfuafa  can  interfere  with 
ita  use,  even  to  tha  extant  that  any  beneficial  properties  are  of  little  consequence.  We  wanted 
to  find  out  whether  tha  requirements  inherently  lead  to  such  complexity  or  whathar  a 
substantially  simpler  lanfuafa  weUd  suffice. 

Three  ground  rules  drove  tha  axparimant  First  no  more  than  two  months  — April  1 to 
May  31  --  would  be  devoted  to  tha  project  Second,  tha  lanfuafa  would  meat  all  tha 
Ironman  requirements  except  for  a few  points  at  which  it  would  anticipate  Steelman 
requirements.  Further,  tha  lanfuafa  wcUd  contain  no  oxtra  features  unless  they  resulted  in  a 
simpler  language.  Third,  simplicity  would  be  the  overriding  objective. 

Tha  resulting  language,  Tartan,  is  baaed  on  all  available  information,  including  the  designs 
already  produced.  The  language  definition  it  presented  here:  a companion  raport  provides  an 
overview  of  tha  language,  a nunber  of  examples,  and  mors  axpository  explanations  of  soma  of 
tha  language  features 

Wa  believe  that  Tartan  it  a substantial  improvement  over  the  earlier  designs,  particularly  in 
its  simplicity  There  is,  of  course,  no  objective  measure  of  simplicity,  but  tha  syntax,  tha  size 
of  the  definition,  and  the  number  of  concepts  reqdrad  are  all  smaller  in  Tartan. 

Meraevar,  Tartan  substantially  masts  ail  of  tha  Ironman  requirement.  (Tha  exceptions  lie  in  a 
♦aw  plecee  where  wa  anticipated  Steelman  requirements  and  where  details  are  still  missing 
from  this  raport)  Thus,  wa  believe  that  a ample  language  caa  meat  the  Ironman  requirement 
Tartan  is  an  existence  proof  of  that 

Wa  must  emphasize  again  that  this  effort  is  an  experiment  not  an  attempt  to  compete  with 
* DOO  contractors  Tartan  ia,  however,  an  open  challenge  to  the  Phaae  II  contractors:  The 

Iwtguage  can  be  at  laaat  this  simple!  Can  you  do  batter? 


This  work  waa  aupported  by  tha  Catenae  Advanced  Research  Projects  Agency  under  contract 
F44620-73-C-0074  (monitored  by  the  Air  Fores  Office  of  Scientific  Research). 
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1.  Basic  Concepts  and  Philosophy 


A program  is  a pieco  of  taxi  that  describes  a sequence  of  action*  intondad  to  offoct  a computation. 
Tho  procosa  of  'executing  a program*  to  obtain  thia  offoct  ia  callod  elaboration  of  the  text  1 

Programming  language*  arc  uaod  for  communicating  program*,  both  between  people  and  between 
people  and  machine*.  Although  the  program  text  ia  static,  the  concept*  being  communicated  are 
dynamic  Thia  dynamic  nature  of  a computation  can  make  it  difficult  to  communicate  the  idea* 
underlying  a program,  and  especially  to  communicate  these  idea*  between  people.  To  expedite  the 
communication,  we  impose  structure  on  the  way  language*  are  uaed  Although  this  structure  restricts 
what  can  be  written,  it  results  in  regular  pattern*  for  expressing  decisions.  The  human  reader  benefits 
from  this  by  developing  expectations  about  how  those  idee*  will  be  expressed. 

Programming  languages  encourage  the  imposition  of  structure  by  providing  notation*  for  the 
structures  whose  use  their  designers  wish  to  promote.  During  the  process  of  language  design,  our 
beliefs  about  programming  methodology  and  tho  state  of  language  procsssing  technology  lead  us  to 
formulate  concepts  and  structural  rule*.  We  than  select  syntactic  forms  and  structuring  features  to 
emphasize  these  concepts  We  expect  that  this  will  simplify  the  task  of  describing  programs  with  the 
attribute*  we  view  as  'good  structure*  and  that  programmers  will,  as  a result,  be  encouraged  to 
organize  their  programs  this  way. 

We  distinguish  three  dominant  structures  in  Tartan  programs:  (1)  the  lexical  structure,  which 
organizes  the  static  program  text,  (2)  the  control  structure,  which  organizes  the  dynemie  execution,  and 
(3)  the  data  structure,  which  organizes  the  information  on  which  computations  are  performed 

- Lexical  structure  is  a property  of  the  program  text  Programs  are  divided  hierarchically  into 
sections,  called  lexical  scopes,  that  share  information  about  data.  Scope  determines  the 
interpretation  of  identifiers,  so  all  the  text  in  a given  lexical  scope  shares  the  same 
vocabulary  — definitions,  variables,  etc  Scop*  rules  permit  soma  identifiers  to  be  used  with 
the  same  interpretation  in  several  lexical  scopes 

- The  control  structure  of  the  program  determines  the  order  in  which  its  statements  are 
executed 

- The  structure  imposed  on  data  involves  the  concepts  of  type,  values,  and  variables 
mtimetely,  computations  are  performed  on  values:  wa  taka  that  notion  to  be  primitive:  values 
exist,  and  each  has  exactly  one  type,  which  determine*  the  legal  operations  on  the  value. 
Value*  are  stored  in  variables,  which  are  objects  produced  by  elaborating  type  definitions 
Variables,  too,  have  types  these  types  detarmina  the  sets  of  values  that  may  legally  be 
stored  in  the  variables 

These  fundamental  structures  interact  in  a number  of  ways  Two  major  interactions  appear  as  the 
concepts  of  extant  and  binding  The  control  and  lexical  atructure*  interact  to  determine  extent  The 
extant  of  a variable  ia  its  lifetime  — the  time  during  which  it  affects  or  is  affected  by  the  elaboration 
of  the  program.  Binding  rules  ars  invoked  by  both  lexical  and  control  structures;  they  associate 
identifiers  with  program  entities  (objects,  modules,  routines  types  labels  and  exceptions). 

In  Tartan,  programs  are  composed  of  definitions,  declarations  and  executable  statements  A 
definition  binds  an  identifier  to  a module,  routine  (procedure,  function,  or  process),  type,  or  exception; 
it  ia  processed  during  translation.  A declaration  binds  an  idontiflor  to  an  object  (is,  • variable  or 
value);  it  io  processed  at  run  time,  usually  to  allocate  storage  Executable  statements  are  elaborated  at 
run  time  to  effect  ectuet  computations  — manipulation  of  values 

lexicel  atructure  ia  impoaed  on  Tartan  programs  by  Mocks  and  modules  which  delimit  lexicel 
scopes  These  scopes  may  be  netted  arbitrarily.  Both  construct*  may  use  identifiers  defined  in  other 
scope*;  both  may  define  identifiers  that  can  be  used  in  other  scopes  Blocks  and  modules  differ  only 


lWe  use  tho  word  'elaboration*,  in  preference  to  ’execution*,  to  connote  actions  taken  during 
translation  a*  wail  ao  djring  execution.  Elaboratian  may  be  thought  of  ea  an  idealized,  direct  execution 
of  the  textual  version  of  the  program. 
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in  thair  scopa  rules  and  in  thsir  affect*  on  tha  extant  of  variable*.  Tartan  ha*  two  *cope  rule*: 

- An  open  scope  inherit*  (import*  automatically)  all  tha  identifiers  that  are  defined  in  its 
enclosing  scope.  It  may  not  export  any  identifiers.  Blocks  are  open  scope*  except  when 
used  as  routine  bodies. 

- A closed  scope  inherits  all  identifier*  that  are  defined  in  its  enclosing  scope  except  those  for 
labels  and  nonmanifest  objects.  I It  may  explicitly  import  identifiers  for  objects,  provided  they 
have  global  extent  All  modules  are  dosed  scopes,  as  are  blocks  when  they  are  used  as 
routine  bodies.  A dosed  scope  that  is  a module  may  export  identifier*  that  name  variables, 
modules,  routines,  types,  or  exceptions. 

Identifiers  that  are  exported  from  an  inner  scope  or  imported  from  an  outer  scope  have  the  status  of 
identifiers  defined  in  the  scope.  Redefinition  of  identifiers  within  a scope  is  not  permitted;  however, 
this  does  not  prohibit  overloading  of  routine  name*.  In  addition,  the  same  identifier  may  be  imported 
with  different  meanings  from  two  different  scope*.  Such  identifiers  are  qualified  with  the  names  of  the 
modules  in  which  they  were  defined;  thus  they  are  not  duplicate  definitions.  Similarly,  literals  and 
constructors  are  qualified  with  their  types  to  prevent  ambiguity.  In  either  esse,  the  module  or  type 
qualifier  may  be  omitted  if  no  ambigiity  arise*. 

In  Tartan,  extent  is  controlled  exclusively  by  blocks  Only  instantiated  objects  (variables,  constants) 
have  extent  Variables  are  instantiated  by  the  elaboration  of  declarations  (for  named  variables)  and  by 
explicit  construction  of  variables  having  dynamic  typs*  (dynamically  created  variables).  Named 
variable*  heve  extent  coincident  with  the  surroutding  block.  Dynamically  created  variable*  have  extent 
coincident  with  the  block  containing  tha  definitions  of  their  dynamic  types  Formal  parameters  of 
routines  are  considered  to  have  extent  cot  no  dent  with  the  routine  body. 

Tartan  provides  a facility  for  making  generic  definition*  of  routine*  and  modules  This  allows  the 
programmer  to  write  a single  textual  dafinition  that  serves  as  an  abbreviation  for  many  closely-related 
specific  definitions  The  definitions  may  accept  parameters;  the  parameters  ara  completely  processed 
during  translation.  The  effect  of  using  a generic  definition  is  that  of  Isxically  substituting  the  definition 
in  the  program  at  the  point  of  use. 

The  syntactic  dafinition  of  Tartan  uses  conventional  BNF  with  the  following  additions  and 
conventions: 

- Key  words  (reserved  words)  and  symbol*  are  denoted  with  boldface. 

- Metasymbols  ara  denoted  by  lower-casa  letters  enclosed  in  angular  brackets,  sg,  *<stmt>". 

- The  symbol*  ( and  } (not  in  boldface)  ars  mats- brackets  and  are  used  to  group  constructs  in 
the  meta-notation. 

- Three  superscript  characters,  possibly  in  combination  with  a subscript  character,  are  used  to 
denote  the  repetition  of  s construct  (or  a group  of  constructs  enclosed  in  {}): 

V denotes  *zaro  or  more  repetitions  of* 
denotes  "one  or  mors  repetitions  of* 

*o*  denotes  'precisely  zero  or  one  instance  of". 

Since  it  is  often  convenient  to  denote  lists  of  things  that  are  separated  by  some  single 
punctuation  mark,  we  denote  this  by  piecing  tha  punctuation  mark  directly  below  the 
repetition  character. 

The  semantics  of  the  language  ars  described  in  English  In  the  interest  of  a compact  and  regular 
syntax,  wo  have  allowed  syntactic  cenotruct*  that  a re  dsallowed  on  semantic  ground*.  This  is 
consistent  with  standard  practice  with  respect  to,  for  example,  undeclared  Identifiers. 


^ Liter*.  i and  identifiers  for  varieties  that  are  declared  manifest  ars  manifest  objects;  hence 
they  are  inherited. 
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2.  Basic  Structures 


2.1.  Primitive  Expressions 

<cort*t>  -jm  { . «dif.t»*  )•  | trua  | laHa  | nil  | daaad  | o aan  I «M  | smety 

I <<onstructor>  | «*d»  | <ouM  *t>  ' <eensl>  | «typs>  * <const>  | <axpr> 

•constructor*  a-  ( <**pc»  • ) I I { <oction»  ->  <axgr>  ),*  ) I " •char*4  * 

Soma  examples  are: 

123.456 
Co  I or 'groan 
trua 

Par ton' <"Seo*.21.aalel 
"afg* 

(1..2->S.1.  3.  .*->0.5.  otWi->1.8) 

Priroitiva  expression*  form  the  baaia  for  the  racuraiva  defintion  of  expressions.  Thay  ara  tha 
afamanta  rafarrad  to  aa  constants,  literals,  and  conatmctora  in  programming  languages  and  aa 
generator*  in  algebras. 

Constanta  and  litaraia  danota  values.  Tha  typa  of  a constant  ia  dotorminod  by  its  dad  oration.  Tha 
typas  of  litaraia  ara  determined  as  follow* 

- A aaquanca  of  digits  containing  no  decimal  point  ia  of  typa  Int  Typa  Int  ia  daftnad  in  tarms 
of  typa  Nxad  for  aach  machina  aa  daacribad  in  Appandlx  1.1. 

- A aaquanca  of  digita  containing  a dadmal  point  is  of  typa  Rsal.  Typa  Raal  is  daftnad  in 
tarms  of  typa  float  for  aach  machina  as  daacribad  in  Appandlx  LI. 

- If  a aaquanca  of  digits,  with  or  without  a dadmal  point,  is  qualifiad  by  a fixad  or  float  typa 
or  by  a dafinad  typa  that  is  ultimately  definad  in  tarms  of  fixad  or  float,  tha  typa  of  tha 
litaral  is  datarminad  by  tha  quaiifiar. 

- Trua  wd  falsa  danota  bootaan  vaiuaa.  Nil  danotas  tha  null  valua  for  any  dynamic  typa.  Opan 
and  dosad  danota  vaiuaa  for  laic  ha  a.  Empty  danotas  tha  amply  sal  Mint  danotas  an 
activation  of  any  process  in  mint  stata 

- A character  string  containing  ons  character  is  a litaral  of  typa  char.  Any  other  character 
string  is  a constructor  of  typa  string. 

Literals  and  manifest  axpraaaiona  ars  evaluated  during  translation  with  tha  same  algorithms  and 
accuracy  aa  ara  used  during  execution. 

If  an  «id»  is  to  be  a <const>,  it  must  have  boon  declared  const  or  be  a member  of  an  enumerated 
type.  If  an  <expr>  is  to  be  a <eonst»,  it  must  be  a manifest  expression 

Tha  typa  of  a constructor  may  be  indented  by  a prefixed  quaiifiar.  if  tha  qMiifier  is  omitted,  tha 
constructor  is  assumed  to  gha  tha  valua  of  an  array  indexed  with  intogors  beginning  at  l. 
Conatructors  ara  provided  for  composite  and  dynamic  typos. 

- If  tha  constructor  has  a record  type,  the  <expr»a  in  parentheses  give  tha  field  values  in  tha 
order  of  their  declaration 

- If  the  constructor  has  an  array  typa,  tha  parenthesized  list  gives  tha  element  values.  If  tha 
constructor  is  a aimpio  expression  Hat,  it  gives  the  vaiuaa  in  order  from  lowest  index  to 
highest  If  tha  constructor  uses  the  form  with  options,  the  expressions  in  tha  <option>e 
indicate  tha  array  position  to  which  aach  valua  corresponds  Tha  special  constant  others  may 
appear  aa  tha  last  <option»;  it  will  match  any  constant  that  ia  not  Included  in  any  other 
< option*.  Tha  constructor  form  with  options  is  togal  only  for  arrays  and  for  typas  ultimately 
dafinad  in  terms  of  arrays  tha  axpraaaiona  in  tha  < option >a  must  bo  manifest 

• If  tha  constructor  has  a variant  typa,  tha  first  expression  in  the  parenthesized  list  is  tha  tag 

and  tha  remainder  of  the  list  is  a constructor  for  the  corresponding  variant 
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- If  the  constructor  has  dynamic  type,  tha  result  is  a pointer  to  a new  veriable  having  the 
attributes  supplied  in  tha  type  qualifier  and  tha  value  given  by  the  pventhe sized  list 

A constructor  conteining  no  <expr>  provides  an  uninitialized  instance  of  tha  indicated  type. 

2.2.  Identifiers 

<vsr  id> 

<r«n*e» 

<option» 

<qual  id» 

<id> 

Soma  examples  are: 

Anieal 'Cat 

V (3) 

VII. .N) 

Sea. Ago 

I d«nt_u  i th_aark 

Identifiers  have  no  inherent  meanings.  They  are  associated  with  objects,  routines,  modules,  types, 
statements,  and  exceptions.  Declarations  and  definitions  establish  the  meanings  of  identifiers  within 
particular  scopes. 

Identifiers  may  be  simple,  or  they  may  be  qualified  with  module  or  type  names  in  order  to  resolve 
ambiguity  among  names  exported  from  several  modules. 

Identifiers  that  name  objects  are  <var  id**.  They  may  be  simple  identifiers,  they  may  be  qualified 
to  indicate  where  they  were  defined,  or  they  may  name  elements  or  substructures  of  composite 
structures. 

- Simple  «var  >d>s  (i.e.,  <qual  id>s  used  as  <var  id>s)  are  identifiers  declared  in  variable 
declarations  or  by  the  <formals>  in  a routine  header. 

- The  form  <var  id*(<actuai*>),  where  <var  id>  denotes  in  array,  denotes  the  element  of  that 
array  indexed  by  the  <actual>e.  The  types  of  the  actuals  must  match  the  index  types  for  the 
array.l 

- The  form  <var  idX<actueis>),  where  <var  id>  denotes  a variable  of  a variant  type  and  the 
<actuai>s  consist  of  a single  <expr>,  indicates  that  the  tag  field  of  the  <var  id>  must  be 
<expr»  and  denotes  the  value  of  that  option  of  the  variant  type.  On  the  left  side  of  an 
assignment,  this  form  has  the  effect  of  setting  the  tag  field;  the  expression  on  the  right  side 
of  the  assignment  must  be  of  compatible  type. 

- The  form  <var  id>(<range>)  denotes  a subarray.  The  <va r id>  must  denote  an  array  and  the 
limits  of  the  <range>  must  match  the  declared  type  of  the  array’s  index  set  and  be  a 
subrange  of  the  declared  range.  The  subarray  consists  of  the  indicated  elements  of  the  <ver 
id>,  in  the  same  order  as  they  appear  in  tha  <var  id>.  If  the  index  type  of  the  array  ia  fixed 
or  defined  in  terms  of  fixed,  the  subarray  is  indexed  by  integers  beginning  with  I;  otherwise 
it  is  indexed  from  the  minimum  value  of  the  index  set  of  the  array. 

- If  <var  id»  denotes  a record  object,  the  form  <var  id>.<id>  denotes  the  field  named  <id>  in 
that  record  object  If  <var  id>  denotes  an  object  of  dynamic  type,  then  <var  id>.<id>  denotes 
tha  field  named  <id>  in  the  record  object  pointed  to  by  the  value  of  <var  *d>;  <var  id>  must 
not  have  the  value  nil.  This  form  is  also  used  to  access  the  value  of  a variant  tag  or  the 
attributes  associated  with  the  type  of  a value  or  variable.  In  addition,  if  T ie  a variable  of 
dynamic  type,  T ell  is  the  complete  value  (ail  components)  of  the  object  associated  with  T. 


<quai  | «v»r  >d»  ( <Ktu*i«>  ) | «v*r  «t>  . <t<J>  | <v«r  id*  ( <rant«>  ) I Hop1  «id» 
<exo r»  . . <#«pr»  | <type» 

( <<On»t>  I <r«n *•»  )_* 

{ <id»  ’)•  <id> 

Oettor*  Oolter  or  _ or  dipt** 


i 


1Note  that  the  index  types  indude  range  restrictions. 
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- Tha  form  Rep’<id»  i*  used  in  the  same  scope  n tha  definition  of  the  <id>’s  typa  to  indteate 
that  tha  <id>  is  to  ba  retarding  as  having  tha  undarlying  typa  This  permits  oparations  on 
tha  undarlying  typa  to  ba  used  for  defining  oparations  on  tha  now  typa 

Identifiers  that  refer  to  definitions  (a.g.,  of  routines,  types,  or  modules)  a re  <qual  id>s. 

When  an  identifier  is  exported  from  a module,  in  the  scope  to  which  it  is  exported  it  is  referred  to 
by  a <quei  id>  or  «va r id>  constructed  by  prefixing  the  identifier  with  the  name  of  tha  moc&ile  from 
which  it  is  exported.  Tha  qualifier  is  separated  from  the  identifier  with  an  apostrophe  Qualifiers  may 
be  omitted  if  no  ambiguity  results. 

\ A <type>  used  as  a range  must  ba  fixed,  an  enumerated  type,  or  a defined  type  that  is  ultimately 

defined  in  farms  of  fixed  or  an  enumeration. 

2.3.  Lexical  Considerations 

Spaces  may  ba  inserted  freely  between  lexemes  without  altering  the  meaning  of  tha  program.  An 
end-of-iina  is  equivalent  to  a space  and  may  not  be  part  of  a lexeme  At  least  one  space  must 
appear  between  any  two  adjacent  lexemes  composed  of  letters,  dgits,  underbar,  and  decimal  pointe  In 
identifiers,  all  characters  are  significant,  but  alphabetic  case  is  not 

Comments  are  introduced  by  the  character  T and  terminated  by  the  next  following  end-of-line. 
They  have  no  effect  on  the  elaboration  of  the  program. 

Although  the  language  as  presented  in  this  report  takes  advantage  of  characters  that  are  not  in  the 
64-character  ASCII  subset,  simple  substitution  to  map  programs  into  that  alphabet  are  defined  in 
Appendix  L 


I. 
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3.  Expressions 


<exor» 

<unop> 
<61000* 
<fun«  esll* 
< actuals* 


<unop>*  <v*r  id*  I <unop>*  <tonsl>  l <unop»*  <lunc  call* 

I <unop»*  ( <a*pr»  ) | ( <a«pr>  ) . <id>  | <a»pr>  <binop*  <a«pr> 
a-  -I- 

* I / I • I - I < M I > 1 1 1 • I l<  I a | cand  | » i ear  | t 
»•  <qual  id*  ( < actual i*  ) 

«expr*i* 


Soma  examples  are: 


X 

say 

sin(x) 

-tatty  * Zttul 
IPoot.Ptrf . aU 


Expressions  describe  computation*  that  yield  value*.  Tha  elaboration  of  an  expression  produces  an 
objact  containinf  the  value  of  tha  expression.  The  type  of  the  object  is  determined  by  tha  following 
rulae: 


“ The  type  s#  an  <*xpr>  that  is  a <v®r  id>,  <const>,  <func  call*,  or  selection  of  a field  from  a 
computed  composite  value  is  determined  by  the  appropriate  declaration  {or  rule  for  literals). 

- Tha  type  of  a parenthesized  expression  is  the  type  of  the  expression  inside  the  parentheses. 

- Tha  type  of  a binary  infix  expression  or  a unary  expression  is  determined  by  the  definition 
of  tha  appropriate  binary  or  unary  operator  definition.  These  operators  represent 
invocations  of  functions  that  may  be  overloaded.  The  appropriate  operator  definition  must 
therefore  be  determined  on  the  basis  of  the  types  of  the  operands 

Tha  usual  operations  are  associated  with  the  operators  ♦,  »,  /,  T,  -,  a,  v,  cand,  cor,  <,  s,  i,  >, 

and  A.  Tha  programmer  may  overload  these  function  names,  but  the  added  definitions  must  be  unary 
or  binary  to  conform  to  the  established  syntax  Precedence  rules  for  the  unary  and  binary  operators 
are  given  by  the  following  table,  in  which  operators  on  a single  line  have  the  same  precedence  and 
operators  higher  in  the  table  bind  more  tightly  then  operators  lower  in  the  table.  Unary  operators 
have  tha  highest  precedence. 


T 

• / 

♦ - 

< S Z > ■ d 
a cand 
v cor 

Within  precedence  levels,  associativity  is  left-to- right 

For  all  operators  except  cand  and  cor,  elaboration  of  an  expression  proceeds  as  if  the  expression 
ware  written  in  functional  form  (see  section  3.  IX  For  cand  and  cor,  the  left  operand  is  elaborated  first 
and  tha  right  operand  is  elaborated  only  if  necessary. 

A manifest  expression  is  a liter*),  a value  of  en  enumeration  type,  an  identifier  declared  with 
manifest  binding,  a generic  parameter,  a manifest  type  attribute,  a constructor  involving  only  manifest 
expressions,  or  any  expression  involving  only  these  expression  and  lenguage-defined  operations.  The 
value  of  a manifest  expression  is  known  during  translation. 
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3.1.  Invocation* 

Soma  axamplas  ara: 

F (5) 

Sequence' Inaart(S.S) 

PI) 

An  invocation  cau*a*  tha  elaboration  of  a procadura  or  function  body  with  tha  elements  of  the 
<formals>  list  of  tha  routine  bound  to  tha  eiamanti  of  tha  <actuals>  list  providad  by  tha  invocation.  If 
a routine  name  i*  overloaded,  the  definition  who**  formal  parameter  type*  match  the  type*  of  the 
actual  parameters  is  selected.  Procedure  and  function  invocation*  (<proc  call>  and  <func  cail>)  differ  in 
that  procedure  invocations  are  statements,  whereas  function  invocations  are  expression*  having  values. 
An  invocation  consists  of  the  following  stops: 

- Elaborate  each  of  tha  <actuais>  in  an  unspecified  order,  yielding  a sequence  of  objects. 

- For  each  result  formal,  create  a variable  having  the  same  type  and  attributes  as  the 
corresponding  actual.  Bind  tha  result  formal*  to  these  variables. 

- For  each  const  or  manifest  formal,  create  an  object  of  the  specified  type  with  the  same 
attributes  as  the  corresponding  actual.  Copy  the  value  of  the  actual  into  the  new  object  l 

- Bind  each  var  formal  to  the  corresponding  actual,  which  must  be  a variable  (l.e^  a <var  id>). 
Thus  var  formal*  are  passed  by  reference: 

- With  the  bindings  established,  elaborate  the  body  of  the  routine. 

- For  each  result  formal,  copy  the  final  value  of  the  variable  bound  to  that  formal  back  into 
the  corresponding  actual,  which  must  be  a variable  (i-e,  a <var  id>).  Note  that  this  actual  is 
determined  before  the  elaboration  of  the  routine  (i.*.,  for  the  actual  A(i),  it  is  the  initial  and 
not  the  final  value  of  i that  determine*  the  variable  that  receive*  the  result). 

The  result  of  a function  is  treatad  a*  a result  parameter  instantiated  at  the  cal)  site  with  extent  as 
described  above  and  passed  as  an  implicit  parameter  to  the  function.  During  the  elaboration  of  the 
function,  its  value  is  developed  in  this  result  parameter. 

During  elaboration  of  a function,  assignment  to  a variable  that  is  not  local  to  the  function  body  (or  to 
the  body  of  a routine  it  invokes,  directly  or  indirectly)  is  permitted  only  if  the  function  is  never 
invoked  in  a scope  where  such  a change  is  mad*  to  a variable  or  component  that  is  directly 
accessible  by  the  caller. 

Actual  parameters  are  matched  with  formal  parameters  positionally.  They  must  satisfy  restriction*  on 
type,  binding  and  aliasing. 

- The  type  of  an  actual  parameter  is  acceptable  if  its  <type  name>  exactly  matches  the  <type 
name>  of  the  corresponding  formal  parameter.  Type  attribute*  (instantiation  parameters  of  a 
type)  play  no  role  in  type  checking.  Chapter  5 give*  rule*  for  determining  <typ*  name>s. 

- The  binding  of  the  actual  parameter  is  acceptable  if  it  matches  the  <binding>  of  the 
corresponding  formal  parameter  according  to  the  following  rules: 

If  the  formal  parameter  is  then  the  actual  parameter  may  be 

var  <var  id*  dadarad  var 

const  <axpr> 

manifest  any  manifest  <axpr> 

result  <v*r  id* 

- Finally,  the  set  of  actual  parameters  must  satisfy  the  following  nonaliasing  restriction:  A 
variable  may  not  be  used  in  more  than  one  var  or  result  position  of  a single  procedure  or 


iNote  that  for  dynamic  types,  this  is  a pointer  copy. 


0 
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procass  call.  For  tha  purpose  of  lasting  this  restriction,  imported  variables  are  considered  to 
be  actual  parameters  bound  as  specified  in  the  import  list 

' 

3.2.  Dynamic  Allocation 

Each  use  of  tha  constructor  for  a dynamic  type  creates  a distinct  element  of  tha  type.  Each  such 
element  remains  allocated  as  long  as  there  is  an  acie.s  path  to  it 

Attributes  of  tha  dynamic  type  are  provided  when  the  constructor  is  used.  Thus  it  is  possible  to 
associate  objects  with  different  attributes  with  the  same  dynamic  variable  at  different  times. 


4.  Statements 

<*<mt»  <proe  C*H»  I *i<i»  1 <stn*f»  | <«mpty»  | 'block* 

| <v*r  id*  !■  <♦»!)'> 

j if  's»pr»  than  <stml».*  ( <«*pr>  than  }•  { afsa  'stmt*.*  J*  H 

j caaa  *e*er»  { on  'option*  •>  'stmt*.*  >*  hk 
| whifa  <a«pr>  da  'stmt*.*  od  | lor  <id>  in  <r*ngp»  da  'stmt*.*  od 
I gala  <id> 

j signal  <qu*l  id*  I resign*!  | marl  <a«pr> 
j <stmt»  { ( on  <id»f*  *>  'stmt*.*  J*  | 
j craaia  <vo r id*  ( 'actuals*  ) 

<proc  call*  «qual  id*  ( 'actual**  ) 

'bloeh*  'coda  body* 

'coda  body*  a-  begin  { <daf-dacl»  s )*  'stmt*.*  and 

Statements  designate  actions  to  ba  performed  Their  siaboration  results  in  changes  in  the  execution 
state  of  the  program.  The  <empty>  statement  has  no  effect  Labels  are  used  by  goto  statements  in 
altering  the  flow  of  control  in  a program.  A label  is  accessible  only  within  the  <stmt*  it  labels  and 
within  a compound  statement  (sequence  of  'itmt>*  separated  by  semicoions)  of  which  it  is  a <stmt>. 

4.1.  Blocks 

Some  examples  are: 

bagin  var  ai  booiaani  * l - trua  and 
begin  a i>  yi  y I*  XI  and 

Blocks  control  extent  A 'block*  is  elaborated  when  control  flows  into  it,  either  because  the  <block* 
is  the  body  of  a routine  that  has  been  invoked  or  because  the  elaboration  of  another  <stmt>  has 
transferred  control  to  it  First  all  declarations  and  the  texts  of  all  module  definitions  are  elaborated,  in 
lexical  order.  Next  the  <stmt>*  are  elaborated  a*  described  elsewhere  in  this  chapter.  Finally,  the 
<block>  is  exited  or  term! noted.  II  it  is  exiled,  control  waits  for  ail  activations  declared  in  this  <biock> 
to  become  dead  or  mint  then  the  extent  defined  by  the  'block*  is  closed  and  all  nondynamic  variables 
instantiated  in  the  'block*  are  deallocated  If  the  'block*  is  terminated,  all  activations  declared  in  the 
'block*  are  forcibly  terminated,  and  then  the  'block*  is  exited  The  choice  between  exiting  and 
terminating  the  block  depend*’  on  how  control  arrived  at  the  end  of  the  block.  If  the  block  came  to 
an  end  because  a handler  completed  or  an  enclosing  process  was  terminated  the  block  is  terminated. 
Otherwise,  it  is  exited 

A 'block*  is  not  permitted  to  export  identifier*.  Except  when  used  as  a routine  body,  it  is  an  open 
scope  and  has  no  naed  to  import  any. 

4.2.  Sequenced  Statements 
Some  example*  arm 

« i*  It  y :•  2i  s )•  3 

SueSq  t-  8:  far  I in  1.  .10  da  SueSq  i-  SuaSq  ♦ VfiltZ  ad 

Sequenced  statements  are  elaborated  in  the  order  given,  except  when  that  order  is  interrupted  by  a 
goto  or  an  exception. 


4.3.  Assignment  Statement 

Some  examples  arm 

VIS). Sue  i.  0 
■ »•  (3  ♦ e)  a y 


E*  is  a procedure  call  on  an  appropriate  assignment  operator, 
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proc  ":«“(v»r  LHSiT,  const  RHSiTI 

for  arbitrary  type  T.  Tha  value  of  the  second  parameter  it  assigned  to  the  object  named  by  the  first 
parameter.  The  parameters  are  of  the  same  type,  and  the  normal  type-checking  rules  apply. 

Assignment  operators  are  defined  for  all  primitive  types.  Assignment  operators  are  defined  for 
arrays,  records,  variants,  and  programmer-defined  types  if  and  only  if  they  have  no  components  that 
are  declared  const  or  are  nonsssignable  by  virtue  of  this  rule.  An  assignment  operator  that  copies  the 
whole  value  is  automatically  suppl;ed  for  each  user-defined  type.  Tor  dynamic  types  this  is  a pointer 
copy.  Although  assignment  may  be  invoked  with  any  variable  and  value  of  the  type,  it  requires  that 
the  attributes  of  its  left  and  right  operands  be  identical,  and  signals  the  BadAssign  exception  if  they 
are  not  The  BadAssign  exception  is  also  signalled  if  an  assignment  involving  mismatched  array,  string, 
or  set  sizes  or  an  activation  not  in  mint  state  is  attempted. 

4.4.  Conditional  Statements 
Some  examples  are: 

if  A < 3 then  x i • y fi 

if  x • 9 eand  y/x  > 0 then  z :•  utty/xl  u :•  1.3i  q i»  y/x  fi 

ease  Tint 

on  fuchsia  -»  Hue  i»  eooli  Description  ■«  “Purplish-red” 
on  puce  ->  Hue  ! * uoraj  Description  :•  “Srounith-purple” 

esse 


In  the  statement  "if  S then  SI  else  S2  fi",  B must  have  type  boolean.  First,  B is  elaborated.  If  the 
resulting  value  is  true,  SI  is  elaborated:  otherwise  S2  is  elaborated.  In  the  absenca  of  an  else  clause, 
S2  is  taken  to  be  the  empty  statement,  which  has  no  effect. 

The  expression 

if  B1  then  SI  slit  82  thsn  S2  ...  siif  Bn  thsn  Sn  sis*  S*  fi 
is  equivalent  to 

if  B1  thsn  SI  sita 
if  82  thsn  S2  slss 

if  Bn  thsn  Sn  site  S*  fi 

fi 

fi 

In  the  statement 

csss  SB 


on  Ell,. 

...Elk  -»  SI 

on  E21, . 

...E2I  ->  S2 

see 

on  Enl,. 

. , . Enn  ->  Sn 

on  othors 
otac 

-»  S* 

The  Fs  must  all  be  expressions  of  the  tame  type,  and  all  except  EO  must  be  manifest  The  type  of 
tha  E"*  n*J*t  be  fixed,  an  enumerated  type,  or  a defined  type  that  is  ultimately  defined  in  terms  of 
fixed  or  an  enumeration.  Any  of  the  Fs  except  EO  may  be  a <range>;  such  an  Eij  ie  treated  as  the 
sequence  of  values  in  the  range.  First,  EO  ie  elaborated  The  Ej  ere  elaborated  and  the  results  are 
compared  to  EO  (in  unspecified  order).  If  EO  is  equal  to  tome  Ej,  the  corresponding  Si  is  elaborated. 
If  all  comparisons  yield  false,  S«  is  elaborated  Exactly  one  Si  it  elaborated  for  each  correct 
elaboration  of  the  ease  statement.  If  the  special  constant  others  does  not  appear  as  the  last  <option> 
and  no  match  is  found  an  exception  (CaseF ailed)  is  signalled 
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4.5.  Loop  StatamanU 
Soma  examples  ara: 


.At  x < 2.5  do  » i»  F(y,x)t  y la  Cty.x)  od 
for  I in  1.  .19  do  V(!)  i>  I od 
for  hue  in  color  do  Tint(huo)  i - huo  od 


Tha  loop  whila  E do  S od  rapaatadly  olaboratoo  it  E than  S fl  until  E bacomaa  faiaa.  It  E la 
initially  false,  tha  loop  haa  no  aftect  (othor  than  tha  poooibio  hidden  ottacto  or  exceptions  cauaad  by 
tha  aiaboration  of  £.) 

Tha  for  otatamant  for  i in  R do  S od  ropoata  tha  steps 

- Bind  i (aa  a constant)  to  a valua  in  tha  ranfa  R. 

- Elaborata  S. 

onea  for  aach  clamant  of  tha  ranfa  R,  in  order.  If  R has  no  elements,  tha  loop  has  no  a ft  act  Tha 
ocopa  of  tha  loop  constant  is  rastrictod  to  tha  loop 

4.6.  Unconditional  Control  Transfer 
An  example  is: 

■oto  L 


Tha  affect  of  a goto  statement  is  to  force  control  to  the  beginning  of  tha  otatamant  with  tha  given 
label.  Since  tha  scope  rules  prevent  inheritance  of  labels  across  dosed  scope  boundaries  and 
importation  of  labels,  a goto  can  not  be  used  to  transfer  out  of  a routine  or  module. 

4.7.  Exceptions 

Soma  examples  ara: 

signal  Toofliy 
assort  x « 8 

rsadf  f 1 1 s.  x)  {on  EOF  •>  goto  Exit  ) 
x|x  x*l  { on  Over  flow  -»  X i«  0 ) 

Exceptions  ara  processed  by  handlor  dsuses  associated  with  individual  statements.  Each  handler 
clausa  associates  processing  coda  with  given  exceptions.  Tha  spedal  identifier  others  may  appear  as 
tha  last  <id>  list  of  a hander  clausa:  it  matches  any  exception  that  is  not  named  In  soma  other 
exception  <id>  list  of  the  same  dausa. 

Whan  an  exception  is  signalled,  control  is  transferred  to  tha  nearest  dynamically  andosing  hander 
clauae  that  hand  os  tha  exception,  either  explidtly  or  through  an  ethers  dausa;  tha  elaboration  of  tha 
handler  replaces  tha  aiaboration  of  tha  remainder  of  tha  statement  If  this  hander  is  not  in  tha 
currently-executing  block,  all  intervening  blocks  will  be  terminated  If  a hander  is  not  found  within 
tha  currently-executing  routine,  that  routine  is  terminated  and  tha  excaption  is  re  signalled  at  tha  point 
of  call  of  tha  routine.  If  a hander  is  not  found  within  tha  currently-executing  process,  that  process  Is 
terminated  and  tha  exception  is  reeignalled  at  tha  and  of  tha  block  in  which  the  process  activation 
was  declared  after  waiting  for  control  to  reach  that  point  and  for  all  other  activations  declared  in  that 
block  to  terminate.  If  no  hander  is  found  in  tha  scope  of  tha  exception  name,  a default  hander  will 
be  supplied  to  terminate  that  block. 

Exiting  a hander  causes  termination  of  the  <stmt>  with  which  it  Is  associated  If  tha  hander 
resignals  the  seme  exception  or  raises  a new  one,  tha  normal  rules  for  exception  processing  apply. 

The  resignal  command  may  be  used  in  any  hander  body  to  resend  the  signal  that  caused  that 
hander  to  be  invoked 
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Th«  assert  statement  ram  tha  assertion  exception  if  the  <axpr>  it  falsa.  It  it  exactly  equivalent 
to  tha  statement  *if  - <axpr>  than  signal  atsartion  fi*. 

Thara  it  ona  axeaption  to  tha  rule  that  an  axeaption  mutt  ba  hand  ad  by  tha  block  in  which  it  is 
signalled  or  by  a callar  of  that  block:  tha  Notify  oparation  on  activationa  or  actnames.  Tha  offact  of  s 
Notify  it  as  if  tha  Tarmmata  axeaption  w ora  signallad  in  tha  currently-executing  ttatamant  of  tha 
activation  na mad  by  tha  Notify  command. 

4.8.  Parallel  Procast  Control 

Soma  axamplaa  ara: 

croala  P(S) 
ectlvatefPl) 

H I s6  locked (PI  I than  . . . 

Tha  craata  command  instantiata*  a procots,  P,  at  an  object  of  typa  activation-of-P.  Tha  <var  id> 
in  a craata  mutt  name  an  object  of  typa  activation-ef-P  that  it  in  mint  state.  If  a process  takas  any 
var  parameters,  tha  corresponding  actual  parameters  must  have  extant  at  least  at  great  at  tha 
activation  variable.  Tha  effect  of  the  craata  it  to  instantiate  an  activation  of  P,  bind  tha  actuals  of  the 
craata  to  tha  formats  of  P,  and  set  tha  activation  in  suspended  state. 

Each  activation  has  a unique  identifying  token  value  of  typa  actname,  and  it  may  ba  named  by  one 
or  more  objects  of  typa  actname.  Except  for  craata,  all  operabons  that  control  parallelitm  are  special 
routines  that  operate  on  either  actnamet  or  activations.  These  routines  control  tha  processes  and 
parallelism  by  changing  and  interrogating  tha  states  of  individual  activations:  they  ara  described  in 
Appendix  1.2. 

Note  that  tha  extent  rules  require  an  activation  to  bo  daad  or  mint  before  tha  block  in  which  it  it 
declared  can  ba  exited.  This  provides  an  implicit  join  operation.  A fork  can  ba  obtained  with  a 
sariat  of  creates  and  activates. 
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a-  «*od<  «selusl*»  1 1 flMl(  <stimk>  ) I ban*  I latch  I char  I Mat  <actuata>  ) 

I •mm(  <*0>/  ] | amaa(  | * <«har»  * )/  J | <aapr*  . . <a*pf» 

I call  <actuai»>  ) I tirintf  <actuata>  ) 
j array  ( <r»nga»/  I at  «typa»  I racara  [ «daetaration>  ♦ J 
I variant  <daclaratwn>  ( [ an  <ophon*  •>  <typa>  (*]  ’ 

I dynamic  *»ypa»  I aativaiian  at  <qu*t  >d»  I aatnama 
I <typa  nama»  ( ( < actual**  J 

»-  fixed  I float  | baaiaan  I lakh  I char  I Ma  | tat  I string 
| anum(  <•«>/  ] I anm(  { * <char>  “ J * J 

I array  [ <ty'pa  «ama»  ♦ j at  <tyoa  nama*  | retard  [ [ <id*  * i <type  nama*  } * ] 

| variant  ( <typo  nama*  ( an  ‘option*  •>  <typa  nama*  )•  ]* 

I dynamic  <typa  nama*  | aettvatien  t equal  id*  ] | actnama 
I <quai  Id*  { [ <«uat  id*/  J )• 

a <type  nama*  may  ba  either  a simple  idantifiar  or  an  Identifier  inflected  with  additional 
Tha  <typa  nama*  to  formed  capture*  ail  tha  information  needed  for  type  checking. 

- Tha  <typo  nama*o  for  tha  primitive  tealar  and  timpla  nonacalar  typed  are  the  kayworda  uaad 
to  declare  thane  fixed,  Heat,  boolean,  letch,  char,  tat,  tiring,  actnama,  file. 

- Tha  <typa  nama*  for  an  array  declared  ’arrayfaJj)  of  0"  ia  *aryay(l,0]-,  whara  I ia  tha  <type 
nama*  of  a and  b. 

- Tha  «typa  nama*  for  an  enumeration  declared  snum(U,L2^.ln]  ia  enum(U,L2*_,U]. 

- Tha  <typa  nama*  for  an  activation  dadarad  activation  of  P it  aetivtlionfP} 

- Tha  <typa  nama*  for  a dynamic  typo  dadarad  dynamic  T ia  dynamic  T. 

• - Tha  «typa  nama*  lor  a record  typa  ia  baaad  on  tha  taquonca  of  field  namaa  and  <typa 

nama*a  in  ita  declaration.  For  a record  dodared  *reeord(Fl:Tl,  F1T2,  _ FreTnf  tha  <»ype 
nama*  ia  'racord(FLTNl,  F2:TN2,  _ FmTNnr,  whara  the  R are  litis  of  field  names,  tha  Ti 
are  types,  and  tha  TNI  ara  type  names.  Bindingt  in  tha  dadaration  do  not  appear  in  tha 
typa  name. 

- Tha  <type  name*  for  a variant  is  •variantnT,Tl-»Vl,T2->V2r^Tn-*Vnr,  whara  TT  is  the 
<type  nama*  of  the  tag,  Ti  is  tho  Ith  value  of  tha  tag  type,  and  Vi  it  tha  <type  name*  that 
corretponda  to  tho  ith  value  of  tho  tag  typo.  Aa  a result,  two  variant  <typa*a  ara  tho  tame  if 
they  tpecify  tha  tamo  <typa*t  for  ail  vakmt  of  tha  tag. 

- Tha  <typa  name*  for  a defined  typa  ia  tho  noma  given  in  tha  typa  definition. 

5.1.  Scalar  Typaa 
Soma  oxampiea  are: 

Real 

1.  .It 

eoum (fuchs i a,  ochre,  puce,  ppf front 


ailt-in  tcaiar  typet  induda  fixed,  float,  baaiaan,  latch,  and  character.  Integer  and  real  must  ba 
constructed  aa  special  caeos  of  fixed  and  float  Ordered  tcaiar  enumerated  typaa  ara  defined  by 
providing  an  ordered  Hat  of  values. 

Typaa  fixed  and  float  require  < actual »>  lists  to  provide  range,  scale,  and  precision  whan  they  are 
uaad  in  declarations.  Theta  ara  attributes  and  do  not  affect  tha  typa  Although  binding*  for  attributes 
may  In  general  ba  canal  or  manifest,  tha  tpedficatione  of  fixed  and  float  require  manifest  attributes. 

To  define  a type,  tha  <axpr*a  In  an  explicit  rang*  must  be  canal  or  manifest 


5.  Typa* 

i 

«tyoe> 


‘type  name* 

\ 


In  Tartan, 
typa  namaa. 


5.2.  Composite  Structures 
Soma  examples  are: 
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array  (1.  .10)  of  Color 
array(Color)  ol  Real 
string!  10) 

record  [Naas:  atr  ing(3S) , Age:  In)) 

variant  bt  boolean  Can  tree  -»  In)  an  Idas  -»  char) 

Nonscalar  data  structural  may  be  built  up  in  three  way*  with  array*  (homogeneous  indexed  linear 
structure),  with  records  (nonhomoganaous  structures  with  named  field*),  and  with  veriest*  (structure* 
whose  substructure  may  vary  with  time).  In  addition,  the  nonscalar  types  set,  string,  and  HI*  are 
defined. 

Legal  bindings  for  fields  of  records  and  variants  are  var,  const,  and  manifest  If  a <bmdmg»  is 
empty,  it  is  taken  to  be  var. 

A variant  type  must  have  exactly  one  tag  field  The  special  constant  others  may  appear  as  the  last 
<optlon>  of  a < variant  type>:  it  matches  any  constant  that  does  not  appear  in  any  other  < option*. 

The  syntax  for  array*  providas  an  abbreviation  for  a set  of  types  pro-defined  as 
"array(lxType£ltType](rr  where  IxType  is  the  index  type,  BtType  is  the  element  type,  and  r ia  a 
(sub)range  of  IxType.  Thu*  *array(1..10)  of  float*  means  *array(inLfto*tXl-10)*  It*  type  name, 
"arrayfinUloat]*.  is  written  *arr«y[int]  of  float".  A*  for  any  type,  when  an  <array  type>  is  used  as  a 
formal  parameter,  the  attribute*  are  not  supplied  The  type  *array<A£)  of  T*  is  an  abbreviation  for 
"errayfA)  of  array(B)  of  T”.  Similarly,  the  array  accessor  *V(g)"  '•  an  abbreviation  for  *V(iXJ)" 

5.3.  Dynamic  Type* 

Some  examples  are: 

dynamic  Rea  I 

dynamic  record  [Oats:  In).  Neat:  LiatElt,  canal  Index!  Int  :•  K) 

Values  of  a dynamic  type  are  pointers  to  variable*  whose  structure  corresponds  to  the  type 
definition.  They  are  initialized  to  nil.  The  extent  of  these  variable*  covers  the  entire  scope  of  the 
type  definition.  Elaborating  a constructor  for  the  dynamic  type  yields  a pointer  to  a new  variable 
distinct  from  all  others.  The  constructor  supplies  the  attribute*  for  this  variable;  they  are  not  supplied 
in  the  declaration  of  the  named  variable  of  the  dynamic  type.  Thus  a named  variable  of  dynamic  type 
may  at  different  times  point  to.  several  different  variables  having  different  attribute* 

5.4.  Process  Control  Typos 

Some  examples  are: 

activation  o4  P 
actnema 

Parallel  processes  are  controlled  with  data  of  two  types  - activation*  of  processes  and  actnames, 
or  names  of  activations.  Activations  are  instantiations  of  a given  process:  an  activation  may  contain  at 
moat  one  process  activation  during  its  lifetime  and  than  only  of  the  process  given  in  its  «type>.  An 
ectname  value  ia  a pointer  to  an  activation.  Actnema  variables  may  contain  pointers  to  activations  of 
•ny  processor  an  actnema  variable  may  refer  to  different  instantiations  of  different  processes  from 
time  to  time. 

An  activation  it  used  to  control  parslle!  or  pseudo-parallel  execution  of  a process  At  any  time  it 
may  be  in  one  of  four  states:  mint,  active,  suspended,  and  dead.  The  extant  of  an  activation  variable 
coincide*  with  its  scope.  The  immediately  enclosing  Mock  cannot  be  exited  until  all  activations  declared 
within  it  are  dead  or  mint  An  activation  ia  associated  with  exactly  one  process,  which  must  be  named 
by  the  «qual  id». 

An  ectname  may  refer  to  any  instantiated  process  A newty-dsdarsd  actnema  or  activation  variable 
it  initialized  to  mint 

5.5.  Defined  Types 

Seme  examples  are: 

Tin) 

Sequence  tint)  (50) 

Programmers  may  define  new  types 


See  section  (5  on  Type  Definitions 
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6.  Definitions  and  Declarations 


<def-decl» 


<declarstion> 
«mod  def» 


«declarshon»  I «nod  0»*>  I <rou(me  d •(»  | <»ype  dei*  I <senertc  dei*  | <emetv* 

| imports  <qual  >d>  * I eiports  <<ju«i  d>  * | wplmi  <kJ>  * | OmMo  <*>  * 

I prig  <proc  «*«*.*  |»  |«rp 

:!•  <b*ndint»  { <><)»  ♦ ( » <type*  )•  { !•  <«ipr»  )•  )*  | cpmdtng*  ( <td>*  i <type  ncme*  )♦ 
3«  medals  <id>  <mod  text* 


<mod  text* 


| <code  body*  | <'»mote  inti* 


‘routine  def* 

<tune  text* 
<proc  tout* 
<typo  dot* 
‘generic  dot* 

‘remote  in«t> 
‘formats* 

< binding* 


pro*  «id»  <proc  test*  | him  <id*  ‘tune  text*  | preisss  <id*  <proc  test* 
j hjnc  * ( <unop>  | <btnop>  < ’ dyne  tail* 

3-  ( ‘forms!**  ) <id»  i <typo»  ; <ttock>  | <ramo(a  mat* 

3-  ( Oormata*  h ‘blocs*  I «r*mote  mat* 

3-  typo  «typo  name*  { ( ‘formslx*  J }•  • <typo* 

3«  generic  module  <id>  [ ‘formsls*  ] <mod  toat*  I gtnoria  tom  <td»  [ Normals*  ] ‘tune  toat* 

| gonoric  proa  «d>  [ ‘formsl**  ] <proc  tail*  | ganoric  proaaaa  <id>  [ <lormait>  ] <proc  toat* 
30  ia  <oual  >d>  [ < actual  a*  ] | im  usumid  I <id»  ) 

30  ( <bmding>  * 1 <typo  name*  }(* 

30  comply*  | »ar  | I a net  | mmHoit  | rscidt 


6.1.  Ddclaratlona 

So  mo  oaompio*  aro: 

var  nt  Root 
conoi  g : ■ true 

var  Huol . Huo2.  Hue3<  Color 

var  Tint  i>  enamUaftron.  puea.  fucnsie,  octvsi 
var  Vj  array  (S.  .7)  at  Int 
var  nitnarklS).  H2:f1arX(7l 
manitaat  Pli  Raal  :*  3.1* 

Tho  syntax  for  dad  orations  allows  thrao  kinds  of  abbreviations.  II  the  initialization  axprpation 
appears,  tho  typo  of  tho  variablo  is  avidsnt  from  tho  <axpr>  and  tho  *<typo>*  may  bo  omit  tod.  In 
addition,  liata  of  <id>s  with  tho  samo  typos  or  bindings  may  bo  condensed  Thaso  abbroviations  aro 
illuatrotod  by  tho  following  five  dodarations,  ail  of  which  have  tho  samo  offset: 

var  a,y  I • 6 

var  a.yi  Int  i * 0 

var  a >•  0,  y t«  0 

var  mint  » 0.  yilnt  i • 0 

var  at  Int  «•  0i  vs r yilnt  t-  0 

Elaboration  of  a dad  oration  causos  instantiation  of  an  objod  which  ia  tha  variablo.  Each  variablo 
has  a typo  and  a value.  Tho  typo  is  dotorminod  whan  it  is  instantiated,  but  tha  value  may  bo  changed 
by  further  elaboration  of  tho  program.  A variablo  may  bo  restricted  to  bo  const  (value  fixed  at  block 
entry)  or  manifest  (value  fixed  during  translation) 

Elaboration  of  a declaration  proceeds  as  follows: 

- Evaluate  tho  <expr»,  if  present,  ft  must  bo  present  in  manifest  or  const  dad  nr  aborts.  It  must 
bo  manifest  in  manifest  dodarations. 

- If  tho  < binding*  is  manifest,  bind  the  value  of  tho  «oxpr>  to  tha  Idsntiflerfs). 

- If  tho  < binding*  is  const  or  var,  elaborate  any  <actuai*e  in  tha  <type>  and  instantiate  a now 
variablo  with  tho  indteatod  typo  and  attributes  for  each  identifier.  If  there  was  an  <expr>, 
assign  its  va km  to  each  of  tho  now  variables. 

Whan  tho  typo  is  dynamic,  tho  dodaration  supplies  tho  <type  name*  only  (no  attributes).  In  this  cose, 
only  tho  pointer  is  alloc  at  ad  at  block  entry;  tho  attributes  are  supplied  whan  tho  dynamic  typo  is 
actually  (dynamically)  allocated 
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6.2.  Module* 

An  example  it: 

modula  Count  or  Oof; 
begin 

export*  Count  or,  Rosot,  I ocr , Vtluo; 
tyta  Countor  • [nt; 

pro*  Reset  (result  CtCountorl;  begin  C i-  0 end; 

pro*  Incrlver  Ci Counter);  begin  C ;•  C ♦ 1 and; 

func  Value  (const  C:Count*r)x:Count*r;  begin  a ;•  C and 

and 

Tha  elaboration  of  a modula  takes  place  during  the  elaboration  of  declaration*  for  the  block  in 
which  tha  mockile  it  defined.  Thi*  elaboration  eontittt  of  elaboratinf  tha  daclarationt  of  tha  modula  in 
laxicai  order,  than  elaboratinf  the  statement*  of  tha  modula 

A modula  or  routine  inherit*  identifiers  for  definition*  (modula*,  routine*,  exception*,  and  type*)  from 
it*  enclosing  scope.  It  may  explicitly  import  identifiers  of  object*  from  that  scope,  provided  the 
object*  have  global  extent  A module,  but  not  a routine,  may  export  definition  and  object  identifier*  to 
it*  enclo*ing  scope.  Type*,  named  routine*,  field  accessor*  for  record*,  and  variable*  are  exported  by 
including  their  name*  in  the  export*  list  of  the  modula  The  right  to  apply  infix  operator*, 
constructors,  subscripts,  "all",  or  the  create  command  for  a type  T are  exported  by  including  the 
special  name*  Tinfix,  Tcon*tr,  Tsubscr,  Tall,  and  Tereate,  respectively,  in  the  export*  ll*t  Literal* 
of  enumerated  type*  are  exported  automatically  if  the  type*  are  exported. 

6.3.  Routines 

Some  examples  are: 


pros  F (var  mint);  begin  « - x;  snd 

p roe  G is  GenG  IS] 

tunc  1 sNi  I (xsOynTiyibeotomt  begin  y i«  l>  • nil)  end 
fun*  *♦*  (a.bigorptcigerp; 

begin 

imports  Bias; 

c t • gorp*  (e.  lef  t*b.  lef tsBIas.  a. rights*. r ightsBies) 

end 


A routine  i»  a closed  scope  whose  body  i*  a block.  Thu*  its  body  control*  extent  for  local 
declarations,  but  doe*  not  inherit  identifiers  for  (non-manife«t)  object*  or  labels.  The  <formal*>  list 
declare*  the  identifiers  for  parameter*. 

A routine  may  be  a function  (func),  which  return*  a value  and  he*  no  visible  side  effect*;  it  may  be 
a procedure  (proc),  which  can  modify  its  parameter*  but  must  be  called  as  a statement;  or  it  may  be  a 
process,  which  is  a potentially-paratlel  procedure;  Special  type-specific  routine*  are  described  in 
Appendix  12. 

Routine  name*  may  be  overloaded  by  binding  tha  same  identifier  to  several  definition*  with  different 
number*  or  type*  of  parameter*  The  function*  for  which  special  infix  notation  i*  provided  are 
obvious  candklata*  for  overloading. 

If  a <binding>  in  a routine  header  is  omitted,  it  it  assumed  to  be  const  The  result  binding  may  be 
used  only  in  procedure*.  No  duplication  of  identifier*  within  the  <formals>  list  I*  permitted,  and 
parameter  name*  may  not  conflict  with  declaration*  or  imports  in  the  routine  body. 

6.4.  Exception* 

Some  example*  are; 

exception  TooBig,  TooSeall,  Lat*.  Singular 
<Bo«Mo  Tooflig,  TooSsal  I 
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The  acopa  of  an  exception  nemo  i*  the  block  in  which  il  it  declared.  A disable  declaration  in  an 
inner  block  suppresses  detection  of  the  exceptions  it  names.  A handler  clausa  associates  recovery 
coda  with  a statement  that  may  (oner ate  an  exception  (sea  section  4.7). 

Tha  disable  dadaration  permits  exceptions  to  be  individually  suppressed  within  a given  scope. 
Should  an  exception  occur  when  its  detection  is  suppressed,  the  consequences  are  not  defined.  An 
exception  must  not  be  signalled  or  redeclared  in  s scope  in  which  it  is  suppressed.  Note  that 
suppression  of  an  exception  is  not  an  assertion  that  the  condition  that  gives  rise  to  the  exception  will 
not  occur. 

Standard  exceptions  will  be  dedared  in  the  global  extent 

5.5.  Type  Definitions 

Soma  examples  are: 

type  Counter  - tnt 

type  tletr  ixlni  Inti  • trrsyd.  .n,l..n)  at  Red 

A user  may  introduce  a new  type  into  his  program  with  s type  definition  The  type  definition  itself 
merely  introduces  the  <type  name>  and  defines  the  representation  of  the  type.  Operations  are 
introduced  by  writing  routines  whose  formal  parameters  are  of  the  newly-defined  type.  Scope 
boundaries,  particularly  module  boundaries,  play  no  role  in  the  definition  of  the  type.  There  is,  as  a 
consequence,  no  notion  of  the  complete  set  of  operations  on  a type: 

A type  definition  may  be  parameterized  The  bindings  in  the  formal  parameter  list  must  be  const  or 
manifest  If  a <bindlng>  is  omitted,  it  will  be  assumed  to  be  const  The  names  of  the  formal  parameters 
of  the  type  are  available  throughout  the  elaboration  of  the  program  as  constants,  called  attributes. 
They  are  accessed  by  treating  the  <var  ident>  as  a record  and  the  type  attribute  ae  a field 
Attributes  for  primitive  types  are  given  as  part  of  the  type  definitions. 

Within  the  scope  in  which  the  type  is  defined,  the  qualifier  Rep  may  be  used  to  indicate  that  the 
object  named  by  the  identifier  Rep  qualifies  is  to  be  treated  as  if  it  had  tha  underlying  type.  This 
allows  operations  on  the  new  type  to  be  written  using  operations  on  its  representation.  When  no 
ambiguity  arises,  the  Rep  qualification  may  be  omitted 

5.6.  Generic  Definitions 

Some  examples  are: 

generis  pres  Reset  f T r tuee)  (rar  »«Th  begin  * i • Vein  end 
pres  ResetCoior  is  Rotat  (Color! 
pres  ResetX  is  Reset (Seee Is! 
ms  dels  Stack  is  assumed  (SteckOef) 

generis  medide  RingOef  (K i tntli 

» »— 

exports  Ring,  Neatti 

type  Ring  • Haedll.l.t.K-Hi 

funs  Next IRiRinglNiRsedil,l,t,K-l)i  bsgw  fi  :•  aod(R*l,K)i  and 

and 

lesduls  RS  is  RingOaMS! 
module  RS  is  RingOeMS! 

A generic  definition  It  syntactically  like  the  corresponding  specific  definition  oxcapt  (hot  it  ia 
prefixed  by  the  word  generic  and  it  may  have  s set  of  generic  parameters  (enclosed  in  square 
brackets)  after  the  definition  name.  For  generic  definitions,  typo  is  acceptable  as  s formal  <type  name>. 

The  actual  parameters  supplied  in  an  instantiation  of  a generic  definition  may  be  any  defined 
identifiers,  including  those  for  variables,  functions,  types,  or  moddes,  or  any  expression.  When  the 
generic  definition  ia  instantiated,  the  text  of  the  acbiai  parameters  replaces  the  Identifiers  that 
represent  the  formal  parameters  The  substitution  is  done  on  a lexical,  rather  then  a strictly  textual, 
basis.  That  Is,  tha  identifiers  in  the  generic  definition  are  renamed  as  necessary  to  avoid  conflicts 
with  the  identifiers  in  the  actual  parameters. 
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Both  generic  definition*  and  remotely-defined  module*  or  routine*  may  be  incorporated  in  a program 
a*  remote  instance*.  A remote  instance  may  be  an  instantiation  of  a generic  definition  or  a reference 
to  a definition  given  elsewhere. 

A module  or  routine  that  is  used  by  the  program  but  whose  definition  is  given  elsewhere  (e.g.,  in  a 
library)  is  incorporated  by  writing  is  assumed(<id>)  as  the  body  of  a module  or  routine  definition.  The 
«id>  is  used  by  a pragma!  to  locate  the  remote  definition. 

A generic  definition  is  instantiated  by  referring  to  it  as  the  body  of  a module  or  routine  definition. 
The  effect  of  the  instantiation  is  as  if  the  generic  definition  were  lexically  substituted  in  place  of  the 
reference  to  it.  That  is,  the  body  of  the  module  or  routine  being  defined  becomes  a copy  of  the 
generic  definition. 

An  instantiation  of  a generic  definition  may  be  used  a*  the  body  of  a specific  module  or  routine.  The 
usual  restrictions  on  defining  new  identifiers  apply  to  the  module  or  routine  being  defined  in  term*  of  a 
generic 

Generic  type  definitions  arise  from  generic  modules.  They  are  instantiated  when  the  module  is 
instantiated.  Thereafter,  they  may  be  used  in  declaration*  or  definition*. 

If  the  generic  definition  has  generic  parameters,  the  actual  parameters  supplied  with  the 
instantiation  must  have  correponding  types  and  be  syntactically  suitable  for  substitution 

If  a generic  definition  is  instantiated  more  than  once  in  a scope,  ambiguous  names  may  be 
introduced.  The  usual  rules  for  resolving  such  ambiguities  apply. 

S.7.  Translation  Issues 

An  exempie  is: 

erst  Optieizelspaceit  UstinglOff)  gs r* 

A program  is  a <biock>.  The  extent  defined  by  the  outer  block  of  the  program  is  the  global  extent 

The  translator  may  be  guided  by  <pragmet>*.  Pragma!*  have  the  same  syntax  as  procedure  calls. 
The  set  of  pragmet  names  and  the  interpretation*  of  the  arguments  are  determined  by  each  translator. 
Translators  will  ignore  pragmats  whose  name*  they  do  not  recognize. 

A program  may  be  broken  into  separately  defined  segments.  This  decomposition  must  take  place  in 
the  global  extent  The  units  of  separate  definition  are  module*  and  routine*.  The  definition 

meOuls  0 it  sssumsd  ( t ) 

in  a segment  has  the  effect  of  making  the  semantics  of  the  segment  the  same  a*  if  the  (separately 
defined)  text  of  Q had  been  substituted  for  *is  assumed!)*  The  identifier  I refers  to  a file,  library,  or 
other  facility  for  storing  separately  defined  segments.  The  relation  between  the  identifier  I and  that 
storage  facility  may  be  established  by  a pragmat 

It  is  a matter  of  optimization  whether  the  separate  definition  is  included  a*  text  or  separately 
translated  and  linked  in.  In  order  to  perform  independent  translation  of  a separately  defined  component, 
it  is  necessary  to  embed  the  module  or  routine  being  translated  in  an  environment  that  supplies 
definitions  for  all  the  names  it  inherits  or  imports.  This  environment  must  form  a complete  program. 
It  ie  assumed  that  the  translation  system  provides  command*  for  selecting  which  components  of  such  a 
translation  to  save  and  for  determining  whore  and  in  what  form  they  are  to  be  saved. 
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I.  Standard  Definitions 


LI.  System-Dependent  Characteristics 

Tha  translate,  tor  aach  systam  is  assumad  to  provida  a modulo  in  tha  global  extent  that  dafinat 
appropriata  systam  constants  Such  constants  ara  assumad  at  various  points  in  tha  language  definition; 
thasa  and  cart  an  othars  ara  summarized  hara  in  tha  form  of  a skeleton  module. 


modulo  Sus  i 



oe|in 

oopsrts  . . . 
typo  tnt  • (bt*d(. 


typa  Rool  ■ Host  I . 


•KCSftlOM  . . . 


t exports  all  definitions  belou 

.1  ‘ ! aopr opr  lots  to  ths  oocnino 

I Nolo  Int.nin  and  Int.ftex  give  rsngo 

.)  ! soproorists  to  tha  oocnino 

! Attributes  give  range,  precision,  scale 

I constants  that  dose i be  properties  of  the 
t object  each  I no 

! procedures  for  accessing  facilities  of  the 
! operating  and  file  sgstees 

I Sgs  tee-defined  exceptions  such  as  Assertion,  BedAss  I gn. . . . 


1.2.  Properties  of  Types 

Alt  types  have  assignment  operators  and  routines  for  conversion  to  appropriate  other  types.  In 
particular,  tha  scalar  types  have  routines  for  converting  to  and  from  character  strings.  Alt  nonscatar 
types  have  constructors  Tha  sections  below  sketch  soma  important  properties  of  the  built-in  types. 


1.2.1.  Fixed 

Literals: 

Attributes: 

Infix  operations: 
Special  routines: 


digit  strings 

Mfa,  Max,  Precision,  Scale 
Arithmetic  and  relational 
rounding,  truncation 


1.2.2.  Float 


Literate: 

Attributes: 

Infix  operations: 
Special  routines: 


digit  strings  with  decimal  point 

Min,  Max,  Radix,  Prod  son,  MinCxp,  MaxExp 

Arithmetic  and  raiational 

rounding,  truncation 


1.2.3.  Enumerations 


All  onumorationo  ara  ordered  The  litorals  ara  assumad  to  appear 
order. 


Literals:  As  given  in  definition 

Attributes:  Min,  Max 

Infix  operations:  Raiational 

Special  routinas:  succ,  prad 


in  tha  declaration  In  increasing 
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1.2.4.  £ooiean 


Liter. 

Attributes: 

Infix  operation*: 
Spaciai  routine*: 

1.2.5.  Characters 

Li  tar  ala: 
Attributes: 

Infix  operation*: 
Spaciai  routine*-. 

1.2.8.  Latche* 


true,  faiae 
none 
logical 
none 


Quoted  character* 
Min,  Max 
none 

at  for  enumeration* 


A latch  is  a simple  spinlock  for  mutual  sxcJution.  If  the  latch  i*  open,  it  I*  avail  obi  e for  siezure:  if  it 
is  dosed,  a Lock  command  will  wait  on  iL 

Literal*:  open,  dosed 

Attribute*:  norm 

Infix  operation*.  none 

Special  routines:  Lock,  IfLocfc,  Unlock 


1.2.7.  Arrays 

Literals:  none 

Attributes:  Range,  BtType 

Infix  operations:  none 

Spadal  operations:  subscript,  subarray,  catenation,  upper  bound,  lower  boind 

1.2.8.  Sat* 

“Sets*  are  boolean  vectors  on  which  tome  additional  operations  ara  defined. 

Literals:  empty 

Attributes:  EH  Type,  MaxSizs 

Infix  operations:  logical 

Spadal  operations:  subscript 


1.2.9.  Dynamic  Types 


Literals:  nil 

Attributes:  The  named  variable  does  not  itself  have  attributes,  but  the  dynamic 

variable  that  it  reference*  may. 

Infix  operations:  nano 

Spadal  operations:  .all  denotes  whole  vaiuo  of  dynamic  object,  a*  dstinguishad  from 

the  reference.  A dynamic  constructor  alloc  ate*  a now  dynamic  object 
Sped  el  routines:  none 


1.2.10.  Record* 

Literals:  none 

Attributes:  individually  defined  with  record  type 

Infix  operations:  none 

Spadal  operations:  field  selection,  constructors 

Spadal  routines:  none 
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1.2.11.  Varianit 


Litarala: 

Attributaa: 

Infix  oparations: 
Spacial  oparationa: 
Spacial  routiner 


individually  dafinad  with  variant  typa 


variant  mutt  ba  designated  to  rafaranca  contenti 


1.2.12.  S trinfa 

Litaral*: 

Attributa*: 

Infix  oparatlon*: 
Spacial  oparationa: 


Quotad  itrinfs 
length 


1.2.13.  Actlvatlan* 


Litoral*:  mini  tfj  j 

Attributaa:  nona  — ~~ 

Infix  oparationa:  non*  ~ ' 

Spacial  oparationa:  craata 

Spacial  routinaa:  To  change  atata:  Activated),  SuapandfA),  UnlockAndSuapandfAX), 

UnloekAndActivatefAj.),  LockAndSuapandfAJ.),  locVAndActlv*t#<A,L), 
TarmnatafA) 

To  quary  atata.  IaMintfA),  IsActyA),  laSuapfA),  I*Tarm(A) 

To  obtain  actnama  NamaOKA),  Mafl 
To  aant  exception:  Notify!  A) 

Other  Pri orityfA),  SatPriorityfA),  Tim*(A) 
where  A ia  an  activation  or  actnama  and  L ia  a latch 

Aaaignmant  cauaaa  the  BadAaatgn  oxcaption  if  either  the  value  or  the  variable  to  which  it  ia  being 
aaaigned  ia  in  a atata  other  than  mini 


Liter  ala: 

Attribute*: 

Infix  operation*: 
Special  operation*: 
Special  routine*: 


1.3.  Alphabatts 

The  following  contaxt-froe  aubatitution*  raduca  the  alphabet  ueed  in  thi*  report  to  the  atandard 
64-character  ASCII  ajbaai  Note  that  aonm  Identifier!  are  pra  amp  tad  aa  a reaull 

For  the  publication  character  Substitute  the  ASCII  string: 
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II.  Collected  Syntax 


<conat* 

'const  ructor* 
<var  id* 
<ranga> 
<option» 

<qu»(  id* 

<id> 

<axpr» 


<unop> 
<binop» 
<(unc  call* 
‘actuate* 
■eetmt* 


<proc  call* 

< blocs* 
<ceda  body* 
«typo» 


<typ#  namo* 


<daf-dacl> 

< declaration* 
<mod  dal* 
<mod  taut* 
«routino  dal* 

<iun«  text* 
<proe  text* 
«typ#  dal* 
‘generic  dal* 

eramota  inat* 

< for  mala* 
‘binding* 


<digil»*  { . <digit>*  )•  | Irua  | tats*  | nil  | daaad  I open  I mint  I amply 
| «conalruetor»  | <ld»  | equal  id*  ' <conat>  | <typa>  * <«onal»  | <axpr> 

( <a»pr>  * ) | ( { eoption*  •>  <axpr»  )*  ) I * echar**  * 

<qua(  id*  I <var  id*  ( ‘actual**  ) | «var  id*  . *W»  I <va r id*  ( <ranga»  ) | Rap’  <id» 

<axpr>  . . <axpr>  | <typa> 

{ <conat>  | ‘fang#*  )* 
a-  { <id»  ’}•  <id* 

elattar*  ‘latter  or  _ or  digit** 

a»  «unop**  <var  id*  | <uoop»*  econat*  | <unop»*  <fync  call* 

| «unop»*  < <axpr»  ) | ( <e*pr»  ) . <id*  | <axpr»  <binop*  <a*pr» 

• | a 

«-  * I / I ♦ I - I < I 1 1 > ! I I • 1*1  A | cand  | v I cor  1 1 
a"  <dual  id*  ( ‘actual**  ) 

<axpr>  • 

:r-  <proe  call*  I <id»  ! <tlml»  | <ampty>  | ‘block* 

| <var  id*  s»  «a*or» 

j if  «a*pr»  than  «»tmt».*  { aUf  <axor»  than  <«tmt».*  )•  { aha  <atmt».*  |*  R 
| caaa  «axpr»  { on  «qplion»  •>  <*tm»»*  }♦  aaaa 
| whMa  <axpr»  da  <»tmt>.*  od  | far  <«1>  in  eranga*  da  <*tmt»,*  ad 
| (Ola  «id> 

| signal  <dual  id*  | reaignel  | aaaarl  <axpr> 

I <*tml»  J { on  *id»  * *>  «atmt».*  }♦  J 
| craata  <var  id*  ( ‘actual**  ) 

:r»  <pual  id*  ( <aclualt>  ) 
a-  <«oda  body* 

a*  bagin  { <dai-dad>  i )*  <»lmt».»  and 

:z~  fixed!  <actuala*  ) I Itoall  < actual**  ) | baalapi  I latch  I char  | DM  <actuala>  ) 

| anum(  <id>  * ] | anum(  ( " <char»  * )/  ] | <axpr>  . . <axpr> 

I call  < actuals*  ) I «tnng(  ‘actual**  ) 

I array  ( eranga*/  ) o!  <typa»  | racard  [ <daclaration>  / J 
j variant  <daclara'lion>  [ ( an  <opiion»  •>  <typa>  )*] 

| dynamic  ‘typo*  | activation  at  equal  id*  I actwama 
j <typa  noma*  ( ( ‘actuals*  ) )• 

a-  fix  ad  | ttaat  | beotaan  t latch  | char  | fila  | amt  | string 
I anum(  eld*  * J I anum(  { * <<har»  * )/  ] 

I array  [ <1y’p#  name*/  j of  <typa  name*  | racard  [ ( «d»  * J <typa  namo*  )/  ] 

| variant  [ <typa  nama*  { an  'option*  ->  <typa  nama*  )*  J* 
j dynamic  <typa  nama*  | artivadan  ( equal  id*  ] | actnama 
j equal  id*  { [ equal  id*/  J )• 

a*  edaciaratian*  I emod  daf*  I erautina  daf*  I <typa  daf*  I ‘generic  daf*  | <emoty> 

| imparta  equal  d>  * I aaparta  equal  d>  * | ancaptian  <d»  * | daabie  <td>  * 

| prag  *Oroc  caH*/  ,•  ftrp 

a-  ebinding*  { «<d*/  { i <typa»  |*  { m «#xpr»  )•  )/  | < binding*  { eld*/  i <typa  nama*  )/ 
maduta  <*d>  <mod  taut* 
a«  t <code  body*  | eramota  inat* 

a«  proa  <id>  eproc  taat*  | ham  <ld>  <fune  tail*  | pracata  <d»  <proc  taxt* 
j tuna  • { <unop»  | <binop»  J * «fune  fast* 
a«  ( etormala*  ) *d>  i <typo>  i ebtoex*  | eramota  inat* 
a*  ( etormala*  )|  <btock>  | eramota  inat* 
a~  typo  <typo  nama*  { ( cfarmala*  ) )•  • *typa» 

a«  ganaria  maduli  <d>  ( etormala*  ] emod  tail*  | generic  tunc  <d»  ( etormala*  ] efunc  last* 

| ganaric  proa  »id>  [ etormala*  ] <proe  last*  | ganaric  pracaaa  <d»  [ etormala*  ] <prac  text* 

la  equal  id*  [ <actuala>  ) | ia  aaiumad  ( <td»  ) 
am  { ‘binding*  <«d»/  i «fypa  nama*  )/ 
a-  <ampty>  | var  | canal  | mantfaat  | raaidt 
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Abstract  continued. 


in  a programming  language  can  interfere  with  its  use,  even  to  the  extent  that  any 

XC  u yet  " 

beneficial  properties  are  of  little  consequence.  Jte  wanted  to  find  out  whether  the 
requirements  inherently  lead  to  such  complexity  or  Whether  a substantially  simpll?*'-^" 
language  would  suffice. 

^""^Three  ground  rules  drove  the  experiment.  First,  no  more  than  two  months  — April  1 to 
May  31  — would  be  devoted  to  the  project.  Second,  the  language  would  meet  all  the 
Ironman  requirements  except  for  a few  points  at  which  it  would  anticipate  Steelman 
requirements.  Further,  the  language  would  contain  no  extra  features  unless  they  resulted  in  a 
simpler  language.  Third,  simplicity  would  be  the  overriding  objective. 

The  resulting  language,  Tartan,  is  based  on  all  available  information,  including  the  design.* 
’already  produced.  The  language  definition  is  presented  here;  a companios  report  provides  an 
overview  of  the  language,  a number  of  examples,  and  more  expository  explanations  of  some  of 
the  language  features. 

We  believe  that  Tartan  is  a substantial  improvement  over  the  earlier  designs,  particularly 
its  simplicity.  There  is,  of  course,  no  objective  measure  of  simplicity,  but  the  syntax,  the 
size  of  the  definition,  and  the  number  of  concepts  required  are  all  smaller  in  Tartan. 

Moreover,  Tartan  substantially  meets  all  cf  the  Ironman  requirement.  (The  exceptions  lie  in 
a few  places  where  we  anticipated  Steelman  requirements  and  where  details  are  still  missing 
(from  this  report.)  Thus,  we  believe  that  a simple  language  can  meet  the  ironman  requirement. 
Tartan  is  an  existence  proof  of  that. 

> ^ k-  * 

must,  emphas ize  again  that  this  effort  is  an  experiment,  not  an  attempt  to  compete  with 
DOD  contractors.  Tartan  is, however,  an  open  challenge  to  the  Phase  II  contractors:  The 
language  can  be  at  least  this  simple!  Can  y&u  do  better? 
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